An IP (internet protocol) multimedia core network subsystem (IMS) is an IP-based network architecture proposed by the 3rd generation partnership project (3GPP), which constructs an open and flexible service environment, supports multimedia applications, and can provide users with abundant multimedia services.
In an IMS service system, a control layer and a service layer are separated. The control layer does not provide specific services, but only provides the service layer with necessary functions such as trigger, routing, charging, etc. The service trigger and control function of the control layer is accomplished by a call session control function (CSCF, categorized into three types as follows: Proxy, Interrogating, and Serving, wherein the Serving plays a major role, and the Interrogating is optional). The service layer is composed of a series of application servers (ASs) and can provide specific services. The AS may be an independent entity or exists in an S-CSCF. The control layer (S-CSCF), according to subscription information of users, controls service trigger and calls services of the AS, so as to implement service functions. The AS and the S-CSCF may be generally called a server equipment (SE). An end-to-end equipment in a session is called a user equipment (UE), responsible for interaction with a user. All the traditional UEs support a circuit switch (CS) network protocol, and all of these CS terminals interact with an IMS network via an IMS network gateway. Since it requires a process to completely upgrade a UE to support an IMS network protocol, some UEs, which may have a limited capability of supporting an IMS protocol, can only support an IMS signaling protocol, but can not support an IMS media protocol; if the UE can also support a CS network protocol, then a medial channel may be provided via the CS network, and such UE is called an IMS centralized service UE (ICS UE). The interaction between the IMS network and the CS network is implemented through a conversion gateway of the IMS network or via a mobile switch center enhanced (MSCe) of the CS network in the IMS centralized service, or may also be implemented by cooperation of the conversion gateway and the MSCe. The part responsible for signaling conversion in the conversion gateway of the IMS network is called a media gateway control function (MGCF), and the part responsible for media conversion is called a media gateway (MGW). The cooperation between the MSCe and the conversion gateway of the IMS network refers to cooperation between the MSCe and the media gateway (MGW) in the conversion gateway of the IMS network, and at this point, the MSCe is similar to the MGCF.
An ultimate objective for a session is to realize media connection, and thus it is necessary to negotiate media resource information in the session. The protocol for negotiating the media resource information in the IMS system is called an SDP (session description protocol). The interaction manner of the protocol is a request-response mode, i.e., one SDP response is necessary for one SDP request, and contents of the SDP request and response are both media resource information comprising media owner information (including address information), media connection address, media type and, media type-related media port and codec information, etc.; in the content of the SDP response, the media quantity, type, and sequence are required to be completely identical to the media quantity, type and sequence in the SDP request. The content of the SDP is included in a message body of a session initialization protocol (SIP), and an interaction process is independent from the request-response mode of the SIP, i.e., a SIP request or response message may include an SDP request, or may include an SDP response, or may not include SDP protocol content.
The IMS centralized service provides a uniform IMS service platform for a traditional user terminal or a terminal merely supporting the IMS signaling protocol, so that various service logics of the user and user information are uniformly provided and recorded via the IMS network. An IMS transfer service enables a user, on the basis that there is already a call, to accept a transfer request of a call counterpart to initiate a call to a third party.
FIG. 1 is a network architecture diagram of an IMS centralized service, illustrating a signaling path for an IMS centralized service terminal ICS UE-A to call an IMS terminal UE-B and a media path for a call between the ICS UE-A and the UE-B after the UE-B responds, the process of which is as follows:                step 101: the ICS UE-A calls the UE-B via the IMS signaling protocol, and a signaling message reaches the S-CSCF;        step 102: the S-CSCF, according to a service trigger rule, sends the signaling message to a centralized-service AS; the AS determines that a calling user cannot establish an IMS media channel, then the AS sends an IMS signaling message to the ICS UE-A to ask it to call a special number over a CS network; through network configuration, signaling of the CS network for calling the special number will be inevitably routed to the AS, and the AS may associate with the call in 102 according to the special number, and the message reaches the ICS UE-A along the paths of 102 and 101;        step 103: the ICS UE-A initiates a call to the special number through a CS signaling protocol, and a signaling message reaches the MGCF or MSCe;        step 104: the MGCF or MSCe informs the MGW to establish a CS media link between the ICS UE-A and the MGW;        step 105: the MSCF or MSCe converts the CS signaling protocol to the IMS signaling protocol, and sends it together with media resource information of the MGW to the S-CSCF;        step 106: the S-CSCF, according to a service trigger rule, sends a signaling message to the centralized AS;        step 107: the centralized AS, according to the special number in the signaling message, associates with the signaling message in step 102, thereby obtaining information about the UE-B which is a true called party, and then forwards the signaling message to the UE-B, the message firstly reaching the S-CSCF along 106, and then being forwarded to the UE-B by the S-CSCF;        step 108: after the UE-B answers the call, a media link between the UE-B and the MGW is established, and the MGW implements a call between the ICS UE-A and the UE-B through switching between the IMS media protocol and the CS media protocol.        
FIG. 2 is a network architecture diagram of establishing a call between a CS network terminal and an IMS network terminal, illustrating a signaling path for the IMS terminal UE-B calling the CS terminal CS-A and a media path for a call between the CS-A and the UE-B after the CS-A responds, the process of which is as follows:                step 201: the UE-B initiates a call to the CS-A via the IMS signaling protocol, and a signaling message reaches the S-CSCF;        step 202: the S-CSCF, according to a service trigger rule, sends the signaling message to a transfer-service AS;        step 203: the transfer-service AS forwards the signaling message to the CS-A, the message firstly reaching the S-CSCF along 202 and then being forwarded to the CS-A by the S-CSCF; since the CS-A is a terminal of the CS network, the IMS signaling message finally reaches the MGCF;        step 204: the MGCF converts the IMS signaling protocol to the CS signaling protocol and sends it to the CS-A;        step 205: the CS-A answers the call, and the MGCF informs the MGW to establish a CS media link between the CS-A and the MGW;        step 206: the MGCF converts the response message of the CS signaling protocol to a response message of the IMS signaling protocol, and sends it together with media resource information of the MGW to the UE-B along the reverse path of the calling message, thereby a media link between the UE-B and the MGW is established, and the MGW implements a call between the CS-A and the UE-B through switching between the IMS media protocol and the CS media protocol.        
Hereinafter, for the convenience of graph drawing and depiction, the AS and the S-CSCF are represented as a same entity, the interaction between them is implemented through a standard IMS signaling flow; the MSCe and the conversion gateway of the IMS network are represented as a same entity, because their functions are quite similar, except that the MSCe is a CS network device, while the MGCF and the MGW (MGCF/MGW) are IMS network devices.
FIG. 3 shows a prior art flow chart of connecting an IMS centralized service with an existing CS media link, which depicts that an ICS UE-A already has a CS media contact, for example, having established a call with a UE-B, and then it is necessary to establish a new media link to connect the existing CS media link, for example, re-calling a UE-C, steps of which are as follows:                step 301: the ICS UE-A establishes a call connection with the UE-B according to a standard IMS centralized service process, the connection comprising two media links, one being a CS media link 51 between the ICS UE-A and the MSCe or MGW, and one being a media link S2 between the MSCe or MGW and the UE-B; in order to initiate a new call, the ICS UE-A sets the call with the UE-B to a hold state, which results in that the media link S2 has no media data to transmit;        step 302: the ICS UE-A initiates a new call to the UE-C via IMS signaling, for example, sending an INVITE message, the message passing through the S-CSCF, and being forwarded to an AS by the S-CSCF according to a service trigger rule;        step 303: the centralized-service AS finds that the calling user of the call is an ICS UE and there is already a call connection, then changes the media resource information in the call message into the media resource information of the MSCe or MGW in the existing call connection, and then forwards the call message;        step 304: the UE-C responds to the call, for example, sending a “200 OK” message of the IMS, the message including the media resource information of the UE-C and reaching the centralized-service AS via the S-CSCF;        step 305: the centralized-service AS receives the response message, and after modifying the media resource information therein according to a standard process, forwards it to the ICS UE-A;        step 306: the centralized-service AS sends a re-invite message to the UE-C, for example, sending a re-INVITE message, the message body including no media resource information; the re-INVITE message includes a session identification corresponding to a media link S3 which is to be newly established (or S3-related session identification), thereby enabling the UE-C to return media resource information for establishing the S3 media link;        herein, S1 is a circuit switch link, S2 and S3 are IP multimedia links, i.e., IMS media links, which are also briefly called herein as media link S2 and media link S3, respectively;        step 307: the UE-C responds to the re-INVITE message, for example, sending a “200 OK” message, the message body including media resource information of the UE-C;        herein, in step 304, the media resource information of the UE-C has already been sent to the AS, and through steps 306 and 307, the AS is capable of sending the modified media resource information of the MSCe or MGW in a response manner to the UE-C in step 310, thereby preventing the UE-C from modifying the resource used by S3;        step 308: the centralized-service AS receives the response message, and then sends a re-invite message to the MSCe or MGCF, for example, sending a re-INVITE message, the message body including the media resource information of the UE-C, and the re-INVITE message including a session identification corresponding to the media link S2, thereby enabling the MSCe or MGCF to update media resource information of the media link S2;        step 309: the MSCe or MGCF responds to the re-INVITE message, for example, sending a “200 OK” message, the message body including the modified media resource information of the MSCe or MGW;        step 310: the AS receives the response message and sends a response acknowledgement message to the UE-C, for example, sending an ACK (acknowledgement) message, the message body including the modified media resource information of the MSCe or MGW;        step 311: meanwhile, the AS sends a response acknowledgement message to the MSCe or MGCF, for example, sending an ACK message.        
Till now, a call connection may be established between the ICS UE-A and the UE-C, the call connection comprising two media links, one being an existing CS media link 51, the other being a new media link S3. Since the existing media link S2 is replaced by S3, the MSCe/MGCF/MGW can correctly connect 51 and S3. The MSCe/MGCF controls, according to the received UE-C media resource information, the MGW to replace the media link S2 with the new media link S3 between the MGW and the UE-C.
FIG. 4 shows a prior art flow chart of connecting a transfer service with an existing CS media link, which depicts that a CS terminal CS-A already has a CS media contact, for example, having established a call with a UE-B, and then the UE-B requests the CS-A to transfer to call a third-party user UE-C, thereby it is necessary to establish a new media link to connect the existing CS media link, steps of which are as follows:                step 401: the UE-B establishes a call connection with the CS-A according to a standard IMS call process, the connection comprising two media links, one being a CS media link 51 between the CS-A and the MGW, and the other being a media link S2 between the MGW and the UE-B; in order to initiate a new call, the UE-B sets the call communicating with the CS-A to a hold state, which results in that the media link S2 has no media data to transmit;        step 402: the UE-B initiates a transfer request to the CS-A, for example sending an REFER (transfer) message, and requests the CS-A to call the UE-C, for example, setting a value of the “Refer-To” header of the REFER message as the identification of the UE-C; the message reaches the transfer-service AS via the S-CSCF;        step 403: the transfer-service AS determines that a recipient of the transfer request is a CS network terminal, and then returns a transfer accept message to the UE-B, for example, sending a “202 Accepted” message, the message reaching the UE-B via the S-CSCF;        step 404: the transfer-service AS initiates a call to the UE-C, for example, sending an INVITE message, and sets the media resource information in the call message as the media resource information of the MGW in an existing call connection, the message reaching the UE-C via the S-CSCF;        step 405: the UE-C responds to the call, for example, sending a “200 OK” message, the message body including the media resource information of the UE-C and reaching the transfer-service AS via the S-CSCF;        step 406: the transfer-service AS sends a re-invite message to the UE-C, for example, sending a re-INVITE message, the message body including no media resource information, the message reaching the UE-C via the S-CSCF; the re-INVITE message includes a session identification corresponding to a media link S3 which is to be newly established, thereby enabling the UE-C to return media resource information for establishing the S3 media link;        step 407: the UE-C responds to the re-INVITE message, for example, sending a “200 OK” message, the message body including the media resource information of the UE-C, the message reaching the transfer-service AS via the S-CSCF;        step 408: the transfer-service AS receives the response message, and then sends a re-invite message to the CS-A via the MGCF, for example, sending a re-INVITE message, the message body including the media resource information of the UE-C, and the message reaching the MGCF via the S-CSCF; the re-INVITE message includes a session identification corresponding to the media link S2, thereby enabling the MGCF to update media resource information of the media link S2;        step 409: the MGCF responds to the re-INVITE message, for example, sending a “200 OK” message, the message body including the modified media resource information of the MGW, the message reaching the transfer-service AS via the S-CSCF;        step 410: the transfer-service AS receives the response message and sends a response acknowledgement message to the UE-C, for example, sending an ACK (acknowledgement) message, the message body including the modified media resource information of the MGW, the message reaching the UE-C via the S-CSCF;        step 411: meanwhile, the transfer-service AS sends a response acknowledgement message to the CS-A, for example, sending an ACK message, the message reaching the MGCF via the S-CSCF.        
Till now, a call connection can be established between the CS-A and the UE-C, the call connection comprising two media links, one being an existing CS media link 51, the other being a new media link S3. Since the existing media link S2 is replaced by S3, the MGCF/MGW can correctly connect 51 and S3.
For the prior art method for connecting a newly established media link to an existing CS media link, after a user responds, i.e., after step 304 or 405, more steps are required to perform media resource re-negotiation before actually realizing a session, which particularly requires participation of a third-party user which very likely belongs to a different network and involves a longer transmission path, thereby resulting in a bad user experience.